Dynamical System

Effect of the actions do not appear immediately - the behaviour evolves with time
Eg. To go from 30 km/hr to 60 km/hr in a car we press the accelerator pedal. We know the card doesn't reach 60 km/hr immedately, it takes a few seconds to accelerate to that velocity.

Mathematical models

Mathematical Representation of a physical, biological or information system. In this class, we focus on dynamical systems (mostly in state-space form)
"All models are wrong, but some are useful". Often, a model is an approximation of the real system. The real system might be too complicated to model perfectly. For eg. aerodynamic interactions between the rotor blades of a quadcopter, friction between the tire and ground for a physical robot etc.
The required modelling accuracy depends on the application at hand. Eg. aerodynamic drag can be neglected for low-speed control design for quadcopters
Analysis and design must performed keeping in mind the limitations of the model

Why models ?

Simulation
Controller design
Verfication and Validaton
Diagnostics, predictive maintenance

Linear Models

Linear models are convenient becuase they're well understood. Lots of tools and techniques are available for the analysis, simulatios, synthesis, simulation, verification etc linear systems. Unfortunately, real world physical systems are never exactly linear. But the behaviour around the desired operating points can be approximated with a linearized version of the actual non-linear modle. Eg. for a quadcopter, the behaviour near hoover condtion can be approximated with linear systems

First order response

Equation is:

\[ \tau\dot{x} + x = u(t) \]

where \(\tau\) is the time constant. The output reaches around 63% of its steady state value with time \(\tau\).

Time Constant: 0.1

Second order response

Equation is:

\[ \ddot{x} + 2 \zeta \omega_n \dot{x} + \omega_n^2x = u(t) \]

where \(\tau\) is the time constant, \(\zeta\) is the damping ratio and \(\omega_n\) is the ntural frequency. One issue with this model is that thinking in terms of the natural frequency is often non-intuitive, unlike the time constant. For damping ratio close to 1, it can be approximated as

\[ \ddot{x} + \frac{2\zeta\dot{x}}{\tau} + \frac{x}{\tau^2} = u(t) \]

. Then, the settling time is around 4 time constants

Examples

Autonomous cars

Cruise Control: Only the velocity needs to be regulated (one state variable). So, first order model is enough

Quadcopters

BLDC Motor modelling: Actually a second order system, but behaves like a first order system due to the high bandwidth (quick response) of the BLDC motor system. Simpler, just one parameter to fit the model (time constant). Widely used in quadcopter simulations (link to fig source )

BLDC first order model

Cascaded control architecture: Due to the first order dynamics of the BLDC motors, the attitude dynamics also have first order behaviour. So, attitude commands can be tracked using tight PID loops at high rates (eg. 500 Hz) with feedback from the gyro and accelerometer. The position control loop can run much slower since it has much slower second order dynamics (eg. 50 Hz)

Simulation

Choice of Simulator

There's no one size fits all simulator. If you're using ROS Gazebo is probably the most convenient one, since it's well integrated into the ROS ecosytem. However, you'll quickly run out of luck if you want to do photorealistic simultion. A game engine like Unreal / Unity would be your best bet here. Similary, you might have to write your own dynamics simulator for specific requirements such as accuarate contact dynamics. Running lots of parallel simulations on the GPU would require another simulator like Nvidia Issac Gym or a custom solution

Choice of Integrator Algorithm and Implementation

Euler forward is the the simplest, but unstable
Runga-Kutta 4th order (RK4) is a bit more complcated, but is mich more accurate
Much fancier algorithms exist (eg. Rosenbrock for stiff ODE's) but RK4 gets the job done most of the time. Popular ODE solvers such Matlab ODE45, scipy ODEint, DIfferentialEquations.jl etc use some fancy version of Rk4 (eg. with adaptive timestepping) as the default algorithm.

Lockstep Simulation

The simulator and autonomy stack wait for messages from each other. Can be used to emulate an RTOS (realtime operating system) based autonomy stack (eg. on a microcontroller) that performs tasks in hard real time, on a non-realtime operating system (eg. linux, windows). Also, this ensures that the simulations are repeatable since messages are never missed.

In the loop simulation

Software in the Loop (SITL)

The actual software stack running on the robot is used for the simulation. New algorithms are typically written in a high level language like C++/python while prototyping. Then, it's ported to a faster low level language like C/C++. SITL simulaitions can be used to validate the real world software stack without actually testing it on the physical hardware

Processor in the loop (SITL)

In SITL simulations, all code is usually executed on the development machine. However, the computing platfroms used on the robot might have severe limitations due to their embedded nature (eg. small flash size,stack overflow etc for microcontrollers). There's a chance that code working correctly on the development machine doesn't work on the onboard computer. To test this, the autonomy stack is run on the onboard computer during simulation.

Hardware in the Loop Simulation (HITL)

It refers to any simulation that involves hardware. The previously mentioned processor in loop simulation is also an example of HITL simulation.

Systems Engineering and Architecture

Architecture is design, and design is art. Much better to explain it using a case study basis. Will as reference paper by Lupashin et al describing the architecure of the Flying Machine Arena (FMA). Well written, contains wealth of information

Everything is a tradeoff

There's no free lunch in systems engineering. Every decision that you take to improve one aspect will be detrimental to some other aspect. Let's see this with a few examples:

a) The older veriosion of the had a Raspberry Pi instead of the Nvidia Jetson. The Jetson is better for image processing (especially ML based) but what's the downside ? Shorter battery life (3-5 W vs 7-15 W) comparison and higher cost (4x higher). These factors not critical for a toy platform duckiebot, but super-important in real life applications. Many of the readers might be familiar with the company Zipline that uses autonomous drones to develop medical supplies. Their flagship platform only a low microcontroller as the flight computer (no high level computers like Raspberry Pi of Jetson). This means that it has much less computing power than the duckibot !. To be fair, it doesn't have cameras, so no heavy image processing. But powerful control methods such as MPC would require something like a Raspberry Pi. So, why stick with the microcontroller when using a Raspberry Pi would enable much better controllers ? Well, you alrready know the answer. The are fighting fro grams and milliwatts to increase the range. Each additional kilometer gained results in a bunch of lives saved.

Resources

Tucker McClure's blog